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MESSAGE FROM THE EDITOR 
By Doug Lockhart, VE/7APU 


Well, it has been a long time since 
the last newsletter and I expect that some 
will have given up hope of receiving 
another newsletter. Keep the faith, we are 
Still active but as usual we find it very 
aifficult to get our newsletter out even 
though there is a lot of news. Efforts are 
being made to get them out more frequently. 
Any donations for the newsletter are for an 
indefinite period of time related to the 
mumber and size of the newsletters sent out 
rather than a specific time period. 

Because of some important new 
developments, this issue mainly concerns 
itself with two very technical items - the 
new V=-2 protocol and the extensions to the 
memory of the VADCG TNC that are necessary 
to support the V-2 software. 

We apologize to those looking for less 
technical material. We will try to get the 
news in the next issue. 


THE VADCG RADIO MODEM 


The VADCG does not have any more of 
the 1200 Baud Radio modem boards or the 
assembled and tested modems and we are not 
planning to make any more of these boards. 
However, we expect to have available a new 
and improved, multi-speed modem board from 
Australia within a couple of months. Sorry 
for the inconvenience. 


THE VADCG TNC 


Because the new V-2 software requires 
either 2716 or 2732 memory chips to run in 
the TNC we are changing the price list to 
separately price the EPROMs and the rest of 
the kit. We recommend the use of 2732s. 
Therefore the ete of the kit has been 
reduced and the EPROMs are separately 
priced. Other price changes have been made 
to reflect the loss in value of the 
Canadian dollar compared to the U.S. dollar 
and changes in our costs. 


The VADCG Terminal Node Controller 
boards and kits are available at the 
following prices: 


SCAN SUS 
199 159 for assembled and tested TNC with 
2708 EPROMs. (Does not include 
power supply or cabinet.) 

for TNC kit for serial (RS232) 
connection. Includes PC board, 
all ram memory, all components 
are socketed. (Does not include 
power supply, cabinet or EPROMs.) 
for same as above less PC board 
ye 18 for TNC bare board only 

25 a4 for Intel 8273 chip 

12 10 for 4 2708 EPROMs 

26 20 for 4 2716 EPROMs 

28 ne for 4 2732 EPROMs 


NEWS SHORTS 


The original Vancouver Protocol has 
been used to communicate between Canada and 
Australia via the Oscar satellite. Stewart 
Beal, VE3MWM and John Tanner, VK2ZxXQ were 
both using VADCG TNCs. 
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Doug Lockhart, VE7APU, made a 
recommendation to the ARRL Ad Hoc Digi’ 
Committee that the CCITT recommendation . 
be adopted as a standard for terminal 
communication in all TNCs. The conversion 
of the V-2 implementation on the VADCG TNC 
to support this recommendation and_ some 
extensions is already mostly complete. 
Details on X-3 will be contained in the 
next newsletter. This recommendation was 
accepted unanimously by the committee. 


Besides, X.3 which offers an extensive 
set of commands for the terminal user, an 
autoBaud function and a dump to terminal 
facility has been added as well. All 
configuration a ae may be changed 
through the keyboard. These features allow 
the same EPROMS to be used at another 
location without modification. Of course, 
the initial defaults are burnt into the 
EPROMs and the TNC will revert to these 
when powered off and on. The modified 
parameters will be held when the TNC is 
reset but not over a power off. Many other 
new features are available. The TIP 
(Terminal Interface Program) has been 
completely rewritten. 


V-2 SOFTWARE AVAILABILITY 


For those who are converting their 
TNCs to 2716s or 2732s according to the 
instructions enclosed, they may receive a 
copy of the the V=-2 software, configuration 
instructions, and user's guide, downline 
dump ogram and some other programs all on 
a CP/M 8-inch SSSD diskette by writing 
the VADCG. Please send sufficient funds 
cover the cost of the diskette and shipping 
costs - about $8 for the U.S. and Canada in 
their own currency and slightly more for 
overseas shipments. Alternatively, you can 
send your own diskette and the programs 
will be put on your diskette and returned. 
Send sufficient funds to cover shipping 
costs - about $3 + a little more for 
overseas shipments. We can also burn the 
program into 2716s on your own chips or 
ones we can supply. We will probably be 
able to do this for 2732s in the very near 
future. We are looking for individuals 
willing to test the new software and 
provide feedback and evaluation reports. 


MAILING LIST CHANGES 


This is the nirth issue of “The 
Packet" and it is being mailed to anyone 
who has ever been on our mailing list. 
Some peorle have been on the iist since 
1979. However, we are finally making some 
deletions to the mailing list which has 
grown to a large size over the years. 


If your mailing label has a red line 
on it, that means that you will not be 
receiving any further issues of the 
newsletter if we do not hear from you. If 
you want the newsletter to keep coming, 
you must communicate with us. Our review 
process may be subject to error and we do 
not want to accidentally delete anyone 
is still interested in receiving “ 
Packet". A donation of $10 for Canada ana 
the U.S. and $15 U.S. for overseas would be 
appreciated to keep the newsletter coming. 


VADCG TNC MEMORY MODIFICATIONS FOR 2716 OR 2732 EPROMS 


The modifications described below allow the VADCG Terminal Node 
Controller (TNC) to use either 2716 or 2732 EPROMs instead of the 2708 
EPROMs supported on the unmodified board. These modifications increase the 
ROM from 4 kilobytes to 8 kilobytes for 2716s or 16 kilobytes for 2732s 
while leaving the random access memory (RAM) still the same at 4 kilobytes. 
These modifications are the ones being supported by the latest software 
being developed by the VADCG and are the ‘approved’ modifications. The 2732 
EPROMS are recommended because they are more cost effective than the 2716s 
and they may be necessary in the future when the software size grows. 


No extra components other than the new EPROM chips are required for 
these modifications. A total of five land pattern cuts are required and 
five jumper wires need to be soldered in. 


1. Land pattern cuts. (the same for both EPROMs) 


1.1. On the component side of the board (front) near the top left corner cut 
the -5 Volt supply trace at the thin section near the plated through 
hole and remove any capacitor which may already be installed at this 
point. The -5 Volt trace is the thick trace which is second from the 
edge of the board. 

1.2. On the solder side of the board (back) cut the traces going to pins 1 
and 2 of US close to the pins. 

1.3. On the solder side of the board locate the trace coming from pin 3 of 
U8 and follow it to the first plated through hole. Cut this trace just 
past the plated through hole. Do not cut the trace between the plated 
through hole and U8. 

1.4. On the solder side of the board cut the +12 Volt supply trace where it 
narrows near the top right hand corner of the board near U18 The +12 
Volt trace is the thick trace the second from the edge of the board. 


2. 2716 Connections 


2.1. Connect pin 23 of U1 (A10) to pin 19 of U18. 

2.2. Connect pin 24 of U1 (A11) to pin 1 on U8. 

2.3. Connect the trace which formerly went to the plated through hole 
connected to pin 3 on U8 (A12) to pin 2 on U8. 

2.4. Connect pin 26 on U1 (A13) to the plated through hole connected to pin 
3 of U8 See 1.3 above. 

2.5. Connect pin 21 of U18 to pin 24 of U18 (+5V). 


3. 2732 Connections 


3.1. Connect pin 23 of U1 (A10) to pin 19 of U18. 

3.2. Connect pin 24 of U1 (A11) to pin 21 of U18. 

3.3. Connect the trace which formerly went to the plated through hole 
connected to pin 3 of U8 (A12) to pin 1 of U8. 

3.4. Connect pin 26 on U1 (A13) to pin 2 of U8. 

3.5. Connect pin 27 on U1 (A14) to the plated through hole connected to pin 
3 of US. See 1.3 above. 


Note: The TNC circuit diagram incorrectly listed A8 to A15 of U1 in the 
reverse order. 


Note: After these modifications the RAM address space is no longer 
contiguous. Each 1K RAM block is duplicated twice for the 2716 modification 
and four times for the 2732 modification. Although this is unconventional, 
it does not pose any problem for the software we have designed for this 
address space. In fact, it is more convenient for managing circular buffers 
than the previous RAM address space allowing the instruction path length to 
be considerably shortened in the 8273 interrupt handlers and other areas of 
the TNC program where management of the circular buffers is involved This 
effectively eliminates re Paonia problem which would prevent the board 
fram operating at its full rated speed of 64,000 Baud due to excessive 
instruction path lengths. 


Doug Lockhart, VE7APU 
October, 1984 
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Abstract 


This paper describes a datalink protocol 
developed by the author in Vancouver. It 
is designed to replace the previous link 
level protocol commonly known as the 
‘Vancouver protocol and it addresses 
all the major limitations of that 
protocol. 
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Preface 


PREFACE TO SEPTEMBER, 1984 EDITION 


This edition of the V=2 protocol document is 
essentially the same in content as the March, 1984 edition 
published in the Third ARRL Amateur Radio Computer 
Networking Conference. The format has been changed and 
a few typographical errors have been corrected. The only 
text changes have been made in Chapter 108 concerning the 
handling of the Ready and Not ready conditions. The 
requirement of sending two RR or two RNR frames under 
certain conditions has been removed, simplifying the 
protocol and making the specification fit the existing 
implementations. This change does not substantially effect 
the operation of the protocol nor result in any 
incompatibility with any implementations designed using the 
previous specification. 


Since the March publication of this document, the 


‘protocol has been implemented on the VADCG TNC and on the 


IBM PC using a special board containing an Intel 8273 chip. 
Both implementations were made using this specification as a 
guide and when tested together, the two systems communicated 
successfully. 


Testing of the protocol and its implementations have 
been made by several groups at different sites. These tests 
indicate that the protocol works as expected with no 
Surprises. Timing comparisons have been done which show 
that this protocol is faster than AxX.25 when transferring 
files. 


1. Historical Background 


Historical Background 


In the summer of 1979 in Vancouver I had a protocol in 
operation in the VADCG TNC which is not well known. It was 
a protocol designed to talk to a ‘Station Node or central 
controller which dynamically assigned addresses to each TNC 
which connected to it. All TNCs communicated to each other 
through the connection services provided by this station 
node. The channel was shared uSing carrier sense multiple 
access (CSMA) techniques similar to most Amateur packet 
operation today. Although this system worked quite well and 
in many respects was more advanced than anything currently 
in use today we had two major problems which have resulted 
in it not being used today. 


Firstly, the station node used the facilities of my S- 
102 CP/M system which was being used to develop both the 
Station node and TNC programs. The VADCG did not have the 
funds or equipment to dedicate to the station node and I was 
not ready to donate my only computer to the cause. The 
group tried to assemble equipment which could be dedicated 
to the station node but were unsuccessful mainly due to 
funding problems. 


Secondly, in the fall of 1979, I was asked by a group 
in Hamilton, Ontario to write a protocol for them which 
would allow communication directly from one TNC to another 
without the need of a station node intermediary. This 
request waS made so that they could use and test the TNCs 
before they assembled the funds to build their own station 
node and then switch over to the Station node based 
software. They had a Similar problem to that of the 
Vancouver group = lack of funds. 


And so, by request, I modified the protocol used to 
communicate to the station node by eliminating the dynamic 
address assignment system and substituting a fixed address 
system and made a minimal amount of changes required to 
provide the requested facilities. Well, as things turned out 
this ‘temporary’ protocol became known as the ‘Vancouver’ 
protocol and became the ‘standard’ in North America for a 
few years. It is still a standard in common use in many 
areas today. We never have gotten back to the older station 
node software although it is still in our plans to do so. 


When I wrote it, I never intended the program to become 
a standard for packet radio communications, only for testing 
TNCS = which it certainly did. It received widespread 
Gistribution mainly because it was the only thing available 
and also because it was capable of doing much more than just 
test TNCS. In spite of its limitations, it still meets the 
needs of most users at the present time. This article is 
written to address those limitations by implementing a new 
link level protocol which I believe can be used as a base on 
which to build network and transport level protocols. 


1. Historical Background 


A meeting of U.S. packet radio groups was held in 
October, 1982 which resulted in the adoption of a protocol 
commonly known aS ‘AX.25° by most U.S. packet radio groups. 
AX.25 addresses most of the limitations of the Vancouver 
protocol but is not a true link level protocol since it 
concerns itself with several network level functions as 
well. It is also undergoing changes at the present time and 
has its own set of problems and limitations. It is my 
preference to have a protocol which makes a clear separation 
of link level and network level functions as per the ISO 
model. As far as standardisation is concerned, when 
signals with other protocols arrive in the area we hope to 
be able to provide a gateway interface to handle then. 


For purposes of discussion I will refer to the orginal 
Vancouver protocol as the ‘Vancouver protocol’ and the new 
protocol as ‘Vancouver Version 2 protocol’ or “V=2° for 
short. 


2. Introdguction 


INTRODUCTION TO V=2 


The V=-2 protocol is intended to be an efficient 
symmetrical and modular datalink level protocol specifically 
for the Amateur Radio environment but potentially usable in 
other environments as well. Both full and half-duplex modes 
are defined. After link establishment, Ve2 has only 5 
octets of overhead per frame in addition to the standard 3 
or 4 octets required for framing. It is strictly a datalink 
protocol and does not provide any network level functions. 
The network level protocol will be provided in a Network 
header which appears only in Information-transfer frames. 
Protocols for the network level and higher levels will be 
the subject of subsequent documents. The VADCG is carrying 
on an ongoing effort to implement and re-implement if 
necessary the best protocols available from a technical 
standpoint. =-. 


All control information for the link and only control 
information for the link is carried in a Link Header and 
Link Trailer which appear at the beginning and end of every 
frame respectively. Only the information not in the link 
control fields need be passed to higher levels of protocol. 
This separation of both function and headers allows software 
for layers to be developed in modular form and permits 
modification of the code for one layer to have minimal 
affect on other layers. 


This protocol makes no claim or intent at comparison or 
Simulation of the CCITT xX.25 level 2 standard. 
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3. Frame Types 


Frame Structure 

All transmissions are sent in frames similar to IBMs 
SDLC and the CCITT’s HDLC as well as to AX=25 and the older 
Vancouver protocol. The frames are encoded in (and decoded 
from) NRZI (Non Return to Zero Inverted) mode by the HDLC 
protocol controller chip. The general field format of a V-2 
frame is as follows: 


CONTROL INFORMATION FCS FLAG 


Field Descriptions 
Sync field 


This field is used for preframe synchronisation. It is 
either 16 bits of zeroes OF sufficient flags for the 
receiving side to establish bit synchronisation. This 
field is basically under control of the HDLC protocol 
controller chip and is transparent to the software. 


Flag fields 


All frames begin and end with a flag which is the bit 
sequence 81111118. When sending multiple frames one after 
the other, the trailing flag of one frame may be used as the 
leading flag of the next frame. The HDLC protocol 
controller chip uses a bit stuffing and deleting technigue 
to ensure that a flag sequence can only appear at the 
beginning and end of a frame. Flags are automatically 
inserted by the HDLC protocol controller chip on transmit 
and are likewise automatically deleted from the data stream 
before passing to the software. i.e. the flags are 
transparent to the software. 


Address field 


This is a four byte address used to identify the link. 
The old protocol used a one byte address. How it is formed 
is discussed later. This field is generated and checked by 
software. 


Control field 

This is a one byte field. It is used to identify the 
type of frame and provides information for supervision of 
the flow of data over the link. This field is generated and 
processed by software. The format of this byte is discussed 
later. 
Information field 


This variable length field is only present in certain 
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3. Frame Types 


types of frames. It must be an integral number of octets. 
Although the hardware allows a maximum length of over 65,8020 
bytes, it is recommended that a maximum length of only 200 
bytes or less should ever be created for transmission. On 
the other hand, the system should be capable of handling 
frames of longer lengths say up to 258 bytes when received 
from other nodes. This allows room for higher level 
Overhead should it be necessary. If unusually long frames 
are to be sent, higher level protocols should agree on the 
Size in advance. 


FCS (Frame Check Sequence) 


This is a two byte field generated as per ISO standard 
3309. This field is automatically generated, checked and 
removed by the HDLC protocol controller chip so I will not 
Giscuss it further. It is used to verify the accuracy of 
the rest of the data in the frame. 


Frame Types 


There are three types of frame formats: unnumbered, 
Supervisory, or information transfer format. The frame type 
is indicated by the value of the low order bit or bits in 
the control field as seen iin storage. (Note that this 
article refers to the fields as they are seen in storage - 
not as how they are transmitted by the protocol controller 
chip) If the low order bit (bit @) is @ then it is an 
information transfer frame. If both bit @ and bit 1 are ] 
then it is an unnumbered frame. Finally, if bit @ is 1 and 
bit 1 is @ then it is a supervisory frame. 


Unnumbered=format frames (U~frames) are used during 
link establishment and termination. They are also used to 
transfer data when the data is not to be checked as to its 
location in a sequence of frames. MThere are a possible 32 
types of U=frames but only three of these are used in this 
protocol. 


Supervisory~format frames (S-frames) are used to assist 
in the transfer of information in that they are used to 
confirm preceding frames carrying information. The frames 
of the supervisory format do not carry information 
themselves. These frames carry an Nr count which is used to 
confirm received frames. They also convey ready or busy 
conditions which assist in coordinating flow control across 
the link and they are also used to report frame numbering 
errors (indicating that a numbered information frame was 
received out of its proper sequence). There are a 
possibility of 4 types of S-frames but only 3 are defined in 
this protocol. 


Information=-transfer format frames (I-frames) actually 


transfer the data from higher protocol levels across the 
Lank. The control field contains send and receive counts 
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3. Frame Types 


(NS and Nr), which are used to ensure that these frames are 
received in their proper order (Ns) and to confirm accepted 
information frames (Nr). The NS count indicates the number 
of the information frame within the sequence of information 
frames transmitted. The Nr count transmitted in a frame is 
the number (Ns) of the information frame that the node 
transmitting the Nr expects to receive next. 


Frame numbering 


A node transmitting numbered I-frames counts each such 
frame and sends the count with the frame. This count is a 
sequence number known aS NS. This sequence number is 
checked by the receiver’s datalink layer for missing or 
Guplicated frames. 


A node receiving I=frames accepts each numbered frame 
that it receives (that is error-free and in=-sequence) and 
advances its receive count for each such frame. The 
receiver count is called Nr. If the received frame is 
error-free, a receiving station's Nr count is the same as 
the Ns count that it will receive in the next numbered 
information frame; that is, a count of one greater than the 
Ns count of the last frame received. The receiver confirms 
accepted numbered I-frames by returning its Nr count to the 
transmitting node. 


The Nr count at the receiving station advances when a 
frame is checked and found to be error-free and in sequence; 
Nr then becomes the count of the "nexteexpected" frame and 
should agree with the next incoming Ns count. If the 
incoming NS does not agree with Nr, the frame is out of 
sequence and Nr does not advance. Out-of=-sequence frames 
are not accepted. The receiver does, however, accept the 
incoming Nr count (for confirmation purposes) if the out-of- 
sequence frame is otherwise error free. 


The counting capacity for Nr and Ns is 8, using the 
Gigits @ through 7. These counts wrap around; that is, 7 is 
sequentially followed by @. Up to seven unconfirmed, 
numbered information frames may be outstanding (transmitted 
but not confirmed) at the transmitter. All unconfirmed 
frames must be retained by the transmitter, because it may 
be necessary to retransmit some or all of them if 
transmission errors or buffering constraints occur. The 
reported Nr count is the number of the next frame that the 
receiver expects to receive, so if, at a checkpoint, it is 
not the same as the transmitter’s next frame (Ns) number, 
some of the frames already sent must be retransmitted. 


The Nr and Ns counts on both ends of the datalink are 
initialized to zero during the link establishment phase. 


3. Frame Types 


The Poll bit (P=bit) and receive timeout. 


The Poll bit is bit 4 in the control field. It is 
used to force a response from the receiving node when set to 
1 (on). Whenever a frame is transmitted with the P-bit on a 
receive timeout is started by the originating node. This 
receive timeout (Tl) is in the order of l]=-3 seconds. This 
timeout is cancelled by reception of any frame from the 
other side of the link. If the timeout expires before the 
expected frame is received then the transmitting node takes 
corrective action. The number of successive timeouts is 
counted and reset when a frame is successfully received. If 
the number of successive receive timeouts exceeds a 
predetermined level (Nl), the next higher level of protocol 
is notified. The higher level may take other action such as 
terminating the link. 


Note that the receive timeout only proceeds when the 
Gata link channel is clear. The timeout is Suspended when 
the data link channel is occupied. On VHF, the datalink 
channel may be occupied by carriers, voice transmissions, 
QRM, etc. in addition to the expected data signals. For 
this reason, it is strongly recommended that CD (Carrier 
Detect) be tested for receive timeouts rather than DCD (Data 
Carrier Detect). All VADCG board installations that I know 
of in Canada are using the squelch line from the VHF 
transceiver rather than the Data Carrier Detect line from 
the modem. Some can select both. If the DCD line is used, 
excessive timeouts will occur and it will be difficult or 
impossible for the TNC program to determine proper action. 
In addition, the TNC will transmit on top of other stations 
using the channel which can lead to unpleasant verbal 
exchanges. Remember that no Amateur frequencies are 
exclusively reserved for this type of packet activity. 


4. Names and Addresses 


NODE NAMING AND ADDRESSING 


Before describing link addressing it iS necessary to 
understand the network node addressing and naming system in 
which this protocol is designed to operate. Also, some 
terms need to be defined. 


Node = In this article the word, ‘Node’ refers to any entity 
in the communications system which originates or receives 
frames. 


Node Names 


Associated with each node in the network is a /? 
character upper case string of ASCII characters. The first 
six characters of which are the Amateur Radio call sign 
padded by ASCII blanks (20 Hexadecimal) on the right. The 
final character is a suffix used to discriminate between 
multiple nodes which have the same call sign. This suffix 
will normally be an ASCII blank (28 hexadecimal) and any 
additional occurrences of the same call sign will be 
identified by the ASCII numbers 1,2,3, etc. Each node in 
the network thus has a unique call sign. 


For example: 
KA6M*** (The * represents a blank) 


Or if KA6M has another node operating: 
KAOM** 1 


Node Address 


Also associated with every node in the network iS a two 
byte (16-bit) binary address. This address can be derived 
from the node name by use of a modified cyclic redundancy 
(CRC) checking algorithm. The algorithm operates on the 7+ 
byte (56 bit) node name handled as a polynomial of degree 56 
and generates a two byte (16~bit) number. 


The algorithm does not generate node addresses with FF 
(hexadecimal) in the first byte because these are reserved 
for special broadcast functions. Please see Appendix A for 
details of the algorithm and a sample implementation for an 
Intel 8@8%8 microprocessor. 


The special destination node address of FFFF 
(Hexadecimal) is used as a general broadcast address and 
Gestination addresses beginning with FF are reserved for 
selective broadcasts and special purposes. 


4. Names and Addresses 


Link Address 


The link address field in the frame is four bytes long 
and is generated by concatenating the 2=byte node addresses 
of the nodes at either end of the link. Each link actually 
has two addresses, identifying the two directions that data 
can flow accross the link. For example, if A and B 
represent the node addresses of linked nodes then AB and BA 
are the two addresses of the link between the pair. Address 
AB represents the link address for data originated by B and 
destined for A while BA represents the link address for data 
originated by A and destined for B. The destination node 
address always comes first. 


5. Implementation Considerations 


Use of Selective Receive 


This link protocol has been designed to make good use 
of the selective receive function available on most 
HDLC/SDLC protocol controllers such as the Intel 8273. The 
8273 can be set to pass to the software only frames which 
have a specific combination of bits in the first byte after 
the leading flag. In this protocol, this byte is the first 
byte of the destination node’s address. If a node does 
selective receive only on the first byte of its address, It 
can eliminate 99.6% (on average) of the link traffic from 
having to be read into memory buffers and analyzed by 
software and yet still be able to do multiple link 
establishments, terminations, etc. 


There are a number of modes of operation possible with 
this protocol using selective receive options as follows: 


1. Selective receive only on the first byte of the nodes 
address for using multiple links as above. This would 
normally be used in anything but the unlinked state but 
would be used in the unlinked state if it was not desired to 
do any of the activities in items 2 and 4 below such as a 
node with a CBBS host. 


2. Selective receive only on address FF (Hexadecimal) to 
monitor broadcast type transmissions and not establish 
links. 


3. Selective receive on address FF and also the first byte 
of the node's address. (2 selective receive addresses are 
Supported on the 8273) Links can be set up and broadcast 
messages can be received. Useful in the unlinked state. 


4. Receive on all addresses. This is not a selective 
receive but it is useful for evesdropping on transmissions 
intended for others or monitoring activity on the channel to 
put it more politely. 


Link States 


Data links are set up and discontinued as required by 
the nodes in the network. They are temporary. The normal 
life history of a datalink usually progresses through three 
basic phases or states namely: establishment, information 
transfer and termination. Although technically not a link 
State, the situation where a node has no datalinks in any of 
the above phases is called the ‘unlinked’ state. 


6. Information Frames 


INFORMATION-TRANSFER FRAMES 


I (Information) frames are numbered. The Ns count 
provides for numbering the frame being sent and the Nr 
provides acknowledgement for the I frames received. When 
duplex information exchange is in continual process, each 
node reports its current Ns and/or Nr counts in each I or S&S 
frame exchanged. I-frames are only originated by nodes that 
are in the information-transfer phase. 


The expected acknowledgement is an S or Il format frame 
whose Nr count confirms correctly received frames. (S= 
frames may be interspersed with I format frames, as needed.) 
An Ieframe always has an I=field, in fact, an I-format frame 
is considered invalid if it does not contain an I~field in 
this protocol. See figure 1 for the layout of the I-frame 
control field. 


Control Field Control Field Bits 
| Type 76: 5 s 3 2 4 9g 


Where; . 

Ns is the send sequence number. 

Nr is the receive sequence number. 
P is the Poll bit. 


Figure 1. I-Frame Control field 


I-Field Content 


The contents of the I-field in an I=-frame are not the 
concern of the datalink protocol. They are determined by 
higher levels of protocol. The design of the V=2 network 
level has not been completed and will be the subject of 
another paper. However, the work on the network level has 
progressed sufficiently that some advice can be given to 
network level implementors and testers that will allow 
different network headers to be identified and to co-exist 
on the same channel. It is for this purpose that the 
following Network level information is included here. 


The first sub-field in the I=field is called the 
Network Header. It is a variable length field composed of 
an even number of bytes. The low order four bits of the 
first byte indicate the number of words (1 word = 2 bytes) 
long the the Network Header is. The high order bit 
indicates if there is another header following the Network 
Header and the three remaining bits are used to identify 
different types of Network Headers that may have the same 
length. 
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The bit layout of the first byte in the Network Header 
is as follows: 


Bit number 7 654321 8 
Poet TUL. a a GL 


Where: F indicates another header follows if l 

T T T indicates the Network Header type 

L LLL indicates the length (in words) of the 
Network Header. 


Even if only the link level protocol is in use the 
following two-byte dummy Network Header should be included 
as the first subfield in the I-field: 

9i@@ (Hexadecimal) 


This will indicate that the header is 2 bytes long and 
that no other header follows this one. 


7. Supervisory Frames 


SUPERVISORY FRAMES 


There are three types of supervisory frames defined by 
this protocol: 


RR Receive Ready 
RNR Receive Not Ready 
REJ Reject 


An S (Supervisory) frame must not contain an Iefield. 
It is considered invalid if it does. See figure 2 for the 
layout of the control field of an S-frame. S-frames are 
only originated by nodes on links which are in the 
information=-transfer phase. 


Control Field 
Type 


aN 
REJ 


Figure 2. S=-frame Control field. 


RR (Receive Ready) 


Indicates that the originating node is ready to receive 
I<frames and acknowledges receipt of numbered I-frames 
through Nr=-l. It must be sent to clear a previous not ready 
condition (RNR). It can also be sent with the P-bit on to 
elicit a response from the node at the other end of the 
link. It is sent with the P<bit off in response to a poll 
by the other side when no I~frames can be sent. 


RNR (Receive Not Ready) 


Indicates that the originating node is temporarily not 
ready to receive I=frames and acknowledges receipt of 
numbered I-frames through Nre-l. It is usually sent when 
buffering limitations and other internal restraints in the 
node are encountered. It can be sent with the P-bit on to 
elicit a response from the node at the other end of the 
link. It is sent with the P-bit off in response to a poll 
by the other side when no I-frames can be sent. This not 
ready condition must be cleared by the sending of an RR or 
REJ frame. Note that the node should still be capable of 
handling S and U frames even in the not ready condition. 
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REJ (Reject) 


Acknowledges receipt of numbered I-frames through Nr-1 
and indicates that the originating node is ready to receive 
I-frames. It requests the retransmission of numbered I- 
frames starting at the Nr contained in the REJ frame. its 
purpose is to speed up recovery of dropped frames when 
operating full duplex. Note that this frame is only used 
with full duplex links and should never be sent on half 
Guplex channels. Only nodes intending to operate full 
duplex need incorporate support for this type of frame. It 
is optional. REJ frames may be interspersed in the sequence 
of transmitted frames on full duplex links. The REJ 
condition is cleared when the requested frame has been 
correctly received. 


8. Unnumbered Frames 


UNNUMBERED FRAMES 


There are three types of unnumbered format frames 
supported by this protocol: 


XID Exchange station identification 
DISC Disconnect 
UI Unnumbered information (formerly NSI) 


Unnumbered frames are not sequence=checked and do not 
use Nr or NS. See figure 3 for the layout of the control 
field for these frames. Although I am using names and 
control field formats common to HDLC/SDLC nomenclature, the 
actual usage of the unnumbered frames in this protocol is 
different. I tried to use the HDLC name with the closest 
approximation to what this protocol is doing. I hope this 
does not cause any confusion. My other alternative was to 
use the undefined HDLC U-frames and give them my own names. 


Note that the previously described I and S-frame usage 
adheres fairly closely to the HDLC/SDLC standards but there 
are major divergences in the usage of the unnumbered format 
frames. This protocol is not intended to be a copy of any 
other protocol but has been designed pragmatically. When a 
piece of another protocol fits the need, it has been used 
but when the need is unique, then unique solutions are 
designed. This method reduces the amount of development 
effort. It also helps those who are familiar with other 
protocols to quickly develop a familiarity with this one. 
On the other hand, there may be some confusion when 
divergences with the other protocols occur. 


Control Field Control Field Bits 
Type 71 & 5 #@. 3-2 4.9 


XID 
DISC 
UI 


Where: 
P is the Poll bit. 


Figure 3. U-Frame Control field. 


XID (Exchange station Identification) 


The XID frame is only used during the link 
establishment phase of the protocol. I was thinking of 
calling it the “LINK’ frame rather than XID. Before I- 
frames can flow across the link, information is exchanged 
between both nodes in the XID frames. The opposite nodes 
XID information is analyzed and a determination is made 
whether or not the link can be established. If both nodes 
like what they see, then the link is established and I and 
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S-frames can flow across the link. On the other hand, if 
one node doesnt like what it sees, then it sends an XID 
frame to the other with a reason code filled in which 
indicates what it didn’t like and the link is not 
established. XID frames are only transmitted on links in 
the establishment phase. The XID frame A, C and I fields 
are as follows: 


AAAACSSSSSSSDDDDDDDPTR 


Where: 

AAAA is the address field. 

C is the control field (XID). 

SSSSSSS is the transmitting node’s 7=byte name. 
DDDDDDD is the destination node’s 7=byte name. 
P is the protocol level field. 

T is the link type field. 

R is the reason field. 


Protocol level field (P-field) 


This 1s a one byte field in the XID frame indicating 
the version of protocol being used by the originating node. 
By testing this field, the receiving node may determine if 
it can communicate with this type of protocol. At the 
present time, this field is @1 (Hexadecimal), indicating 
this is Level @ of the protocol (bit @ is on). This version 
number should be changed whenever a new level is produced 
which has features or changes which are not compatible with 
previous levels. This feature has been added in 
anticipation of future revisions and extensions of the 
protocol. 


The receiving node checks for a match on this field. 
Note that a node may Support multiple levels of protocol in 
Order to communicate with nodes of different levels. For 
example, a primary station which supports multiple protocols 
may send an XID saying that it can communicate with levels @ 
and 1 of this protocol by sending a Pe-field of 63 
(Hexadecimal) with bits @ and ] on. The secondary 
determines if communication is possible by and’ing its own 
version(s) with that in the incoming Pefield. If the result 
of this operation is non-zero, then the protocol levels are 
compatible and the secondary will respond with a P-field 
indicating which protocol it is using. If the result of 
this operation gives more than one bit on, then the 
secondary can choose which of the protocols it wishes to 
use. 


For example: 


1. Primary sends P-field of 83 indicating it can support 
levels @ and l. 


2. Secondary logically ‘ands’ the primary’s P-field with its 
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Own protocol version number of @1 (Only Supports level @Q). 
The result is @l. 


3. Since the result was nonezero, the protocols are 
compatible and the Secondary can respond with a P-field 
value of 91. On the other hand, if the result 1s zero, then 
there is a protocol incompatibility and the secondary will 
respond with the protocol mismatch bit (another P-bit) set 
in the Reason field (R=-field). The link will not be 
established. 


Link type field (T-field) 


The T-field is a one byte field in the XID frame 
indicating the type of link being established. At present 
the only choice in link type is either full duplex or half 
duplex. The byte format is as follows: 


Bit number 7 654321 8 
X X X X X XX F 
Where X indicates reserved bits = must be @Q 
F indicates full duplex if 1, half duplex if @ 


This field is checked by the receiving node and if it 
is capable of handling the type of link indicated it will 
respond with a matching indication in its own Tefield. But 
if, for example, the primary requests a full duplex link and 
the secondary only has support for halfeduplex, the 
secondary will respond with the Link type mismatch bit (T- 
bit) set in the reason field (R-field). 


Reason field (R-field) 


The reason field is a one=byte field in the XID frame 
used by the secondary to report to the primary the reason 
why the link is not being established. If any bits are on 
in this field, the link was not established. The R-field 
layout is as follows: 


Bit number 7654321 @ 
X X X X ART P 
Where: 
X = reserved bit = must be @. 
A - Address duplication (See Restrictions) 
R - Resource limitation 
T - Link type field mismatch (see T=-field desc.) 
P = Protocol mismatch (see P-field description.) 


The R=bit being on (1) means that the originating node 
has a temporary resource shortage which prevents the 
establishment of the link. The most likely reason being 
that it has a limitation on the number of simultaneous links 
that the node can support. Most nodes used in Amateur Radio 
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so far can only support one link at a time, and so, if a 
node has this link already established when it receives an 
XID frame from a third party node, it should respond with 
the R=-bit turned on. 


Link Establishment 


For purposes of the following discussion the node 
initiating the connection transmits first and is called the 
‘primary node. The node being connected to is called the 
“secondary node. This distinction is made because the 
primary and secondary nodes use some of the fields in a 
Slightly different way. This is a different use of these 
terms than is found in other protocol documents. 


The following chart shows a normal link establishment 
between the primary node whose address is A and the 
secondary whose address is B. 


BA,XID=P -~=> Primary transmits XID 

<-=-- AB,XID Secondary transmits XID 
BA,I-P -~--- > Primary transmits I 
ecco. 


Conflict Resolution 


Although unlikely, there is a possibility of the 
occurence of conflicting requests during the link 
establishment phase. This is not possible during other link 
phases. A conflict occurs if two nodes try to initiate a 
link with the other at the same time but with conflicting 
requirements. For example, one node wants to establish a 
half-duplex link while the other wants to establish a full- 
Guplex link or the protocols they want to use are different. 
Even if both sides take the same recovery action this still 
does not solve the problem. One side must gain the upper 
hand. The resolution method chosen is that the node with 
the higher address gets itS way and the node with the lower 
address must report to its higher level that a link was 
established but not with the desired specifications due to 
contlict: 


Disconnect frame (DISC) 


The DISC frame is only sent during the link termination 
phase and it is the only type of frame that can be sent on 
links in the termination phase. I think this frame would 
better be called ‘Unlink” because that is a better 
description of the function it performs. Connections (in my 
Opinion) are the concern of higher protocol levels = not the 
Gatalink level. The DISC frame is only sent after the link 
has been established and indicates that the originator will 
no longer send or receive I and S=frames on the link. It is 
sent with the Poll bit on by the primary node (The node 
initiating the link termination) and sent with the poll bit 
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off by the receiving secondary node to indicate that it will 
no longer send I and S=frames on the link. 


The format of the DISC frame is the same as that of the 
XID frame described above except that the usage of the P, T 
and R fields is different. In the DISC frame the Reason 
field (R-field) indicates the reason for the disconnect when 
sent with the Poll bit on by the primary node. If the R- 
field has no bits turned on this is a normal link 
termination but if a bit or bits are on in the R-field, then 
this link is being terminated because of an error. The R- 
field bits are defined as follows: 


Bit number 7 65 4321 8@ 
@080002Y XW 
Where: 
l. If Wis on, the originating node has received an 


invalid or non-implemented control field. 


‘e If x is on, the originating node has received a frame 
with a prohibited I-field. 


35 If Y is on, the originating node has received an I- 
frame with a length greater than the maximum the node can 
Support. 


4. If 2 is on, the originating node has received a frame 
with an incongruous Nr. 


If any of the bits are on in the R~-field, the P-field 
contains the control field of the frame received which 
caused the error condition and the T-field contains the 
following information: 


Bit number 7 6 5 4 3 2 1 4) 
Vr 4) Vs B 


Where Vr is the next expected NS value to be received 
and Vs was the next NS value to be sent at the time the 
error was detected. 


The P,T and R fields are undefined (and should be 
ignored) in a DISC frame with the Poll bit off. Similarily, 
the P and Tefields are undefined in a DISC frame with a 
value of @ in the Refield. 


Even though the node names are unnecessary from a 
technical point of view in the DISC frame, they are included 
in the Amateur Radio environment to give information to 
other nodes monitoring the channel as to who the two nodes 
are who have terminated the link between them. The names 
are also sent out when the link is being established as 
well, This is somewhat similar to the Amateur practise of 
identification at the beginning and end of each QSO. 
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Unnumbered Information Frame (UI) 


The UI-frame is included in this protocol as a method 
of transmitting information when a link has not been 
established or for bypassing the normal handling of I-frames 
when a link is established. One example of such use would 
be a repeater identifying itself every few minutes = a type 
of broadcast message. It is included in the protocol 
because of a need in the Amateur Radio environment for such 
a function. 


Since UI~frames are unnumbered, they should not be 
acknowledged whether or not they are transmitted with the 
Poll bit on or off. If one is lost, there is no way of 
recovering it. No error reporting is done for UI frames and 
the UI frame should only be passed on to a higher level when 
the data link is not established, not being established and 
not being terminated. For use aS a type of general 
broadcast, the link address field in a UI=-frame should use 
the special general broadcast address of FFFF (Hexadecimal) 
as the first two bytes of the link address. If the 
broadcast is only intended for a specific area then the 
first byte should be FF and the second byte should be an 
area Or group number. And if it is intended for a specific 
node then that node's address can be used in the first two 
bytes. 
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Responses to polls 


When a node receives a frame with a P=bit on, it must 
respond. The type of response varies depending on the type 
of frame that contained the P-bit. The response frame does 
not have the P-bit on except in the ease of the I-frame 
response where the P-bit is allowed. The responses possible 
for each type of frame containing a P-bit are shown in 
Figure 4 following: 


Polling Frame Type Responding frame(s) 


I or RR Or RNR or REJ* 
I or RR or RNR 
RR Or RNR 


XID 
DISC 
none 
I 


* = REJ only used in full-duplex 


Figure 4. Poll Responses 


1@. Half-Duplex Procedures 


HALF=DUPLEX PROCEDURES 


Half-duplex links assume that only one side transmits 
at a time. For this reason they can be used on a Single 
two-way communications channel. Half duplex protocols can 
also be used on independent transmission channels as well 
but full-duplex would be a more efficient method when these 
facilities are available. Channel sharing with multiple 
nodes require half duplex protocols. V=-2 provides a half- 
duplex multipoint protocol. This protocol can be used in a 
point-to-point environment as well with very little 
reduction in efficiency compared with a protocol only 
designed for point-to-point work. 


Information transfer 


When a node has one or more I-frames to send, it sends 
them in sequence and in conformity with the requirements 
described in “Frame numbering" previously. Since I-frames 
always reguire a response, the P=bit is turned on in the 
last frame of the transmitted sequence of I-frames. The 
exception to this rule occurs when it is necessary to 
transmit an S-frame with the P-bit on in the same 
transmission as well. In either case, a receive timeout is 
started at this time as previously described in the section, 
"The Poll bit and receive timeout". The node then turns the 
link around and listens for a response. Note that the 
reception of an I=frame with or without the P-bit on demands 
a response. 


If the receive timeout expires, meaning nothing was 
received, the node will not retransmit the previous frames 
but transmit an RR or RNR frame with the poll bit on and 
again wait for a response. This operation repeats itself 
until something is received from the other side. (The 
higher level of protocol is notified after every Nl 
consecutive timeouts.) 


When a response is received, the node starts 
transmitting I-frames again, beginning with the first 
unacknowledged I-frame. 


Not ready condition handling 


When a node becomes not ready to receive I=frames on a 
link it will send an RNR frame with the poll bit on at the 
earliest opportunity. If permitted by the other side, I- 
frames may be sent along with the transmission of RNR but 
Only the RNR frame should have the poll bit on in this case 
and it should be sent last in the transmission. The node 
then listens on the link. 
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If the receive timeout expires, only the RNR frame with 
the poll bit on 1s retransmitted. If an I-frame is heard 
the RNR frame with poll bit is retransmitted. (Note —- the 
node may accept or ignore the I~-frame at its discretion even 
though it is trying to tell the other side to stop sending 
them.) 


If an RR or RNR frame with the P-bit on is heard, the 
node should respond with I-frames followed by an RNR frame 
with the P-bit on if it can send I-frames or otherwise by 
transmitting an RNR framewith the poll bit on. Finally, if 
an RNR or RR frame with the P-bit off is received this will 
be accepted by the node as an indication that the other side 
is aware of the not ready situation and the node can go back 
to sending I-frames if it has any to send and is permitted 
to send them. Most of these actions can be deduced from 
Fig. 4 above. 


Note that no node is permitted to send I-frames after 
receiving RNR and before receiving RR. 


Ready condition handling 


When a node becomes ready to receive I=frames on a link 
it will send an RR frame with the poll bit on at the 
earliest opportunity. If permitted by the other side, I- 
frames may be sent along with the transmission of RR but 
only the RR frame should have the poll bit on in this case. 
The node then listens on the link. 


If the receive timeout expires, only the RR frame with 
the poll bit on is retransmitted. If an RR or RNR is heard 
with the poll bit on the node should respond by either 
transmitting I-frames followed by an RR with the poll bit on 
Or otherwise by transmitting an RR frame with the poll bit 
on and start a receive timeout. If an RNR or RR frame with 
the P-bit off or an I-frame is received this will be 
accepted by the node as an indication that the other side is 
aware of the ready situation and the node can go back to 
sending I-frames if it has any to send and is permitted to 
send them. 
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FULL=DUPLEX PROCEDURES 


A full duplex link requires two independent channels 
for the transfer of data. The full duplex protocol is 
designed so that it is possible for both sides to 
continuously transmit data to the other side simultaneously. 
One channel is used for transmissions by node A for example 
and the other channel is used for transmissions by B. 
Because of the potentially continuous nature of these 
transmissions, it is usual that each node never listens on 
its own transmitting channel. However, a node may delay its 
transmissions if it has some way of knowing that its 
transmitting channel is unuseable. 


This version of V=-2 only defines a point-to-point full- 
duplex protocol. This has uses in ‘backbone’ linking for an 
Amateur Radio digital communications network and for 
satellite work. It 1S an option which does not have to be 
implemented in all nodes. Extensions to V2 for multipoint 
full duplex operation are being planned but are not within 
the scope of this paper. 


Information transfer 


In full-duplex each node listens even when 
transmitting. Frame numbering and acknowledgment is similar 
to half-duplex except that acknowledgments are done ‘on the 
fly even while the other side is transmitting. 


A node sends I-frames in sequence until it either has 
no more frames to send or there are 7 frames outstanding. 
At this point it will put the P-bit on in the final frame to 
request acknowledgement from the other side and begin a 
receive timeout. In order to improve throughput on links 
with a long turnaround delay = such as satellites, it is 
permissible to put the poll bit on ina frame before 7 
frames are outstanding and still continue to transmit up to 
the maximum of 7 unacknowledged frames. This technique is 
called ‘pacing’. 


If the receive timeout expires meaning nothing was 
received, the node will not retransmit the previous frames 
but transmit an RR or RNR frame with the poll bit on and 
again wait for a response. This operation repeats itself 
until something 18S received from the other side. (The 
higher level of protocol is notified after every Nl 
consecutive timeouts.) 


When a response is received, the node starts 
transmitting I=-frames again, beginning with the first 
unacknowledged I-frame. 


If a node receiving sequenced Ieframes encounters a 
frame not in sequence it should send a REJ frame at the 
earliest opportunity it gets. The node receiving the REJ 
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should go back to transmitting the last unacknowledged frame 
and continue from there. The node should not transmit any 
more REJ frames until the reject condition is cleared by the 
receipt of the numbered I-frame indicated in the REJ frame. 


Not ready condition handling 


Not ready conditions are handled similarly to that 
described in the half-duplex environment except that the 
channel doesn’t have to be turned aroun. 


Ready condition handling 


Ready conditions are handled basically the same as 
described in the halfeduplex procedures. 
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THE BIG PICTURE 


The datalink layer of protocol described herein is only 
one part of a complete communications protocol. As per the 
suggested ISO protocol layering structures, this protocol 
only interfaces with the two adjacent layers in the node in 
which it is running and with the datalink layer on the other 
side of the link. 


The datalink layer receives data and orders from the 
Network layer immediately above it. The network layer is a 
‘higher’ level of protocol and sort of acts like the 
datalink layer’s ‘boss’. The datalink layer acts on these 
commands and reports on its progress and status as the job 
is done. When unusual conditions occur which the datalink 
layer can’t handle it goes to its ‘boss’ for advice. 


The datalink layer passes data and commands to the next 
lower protocol layer - the Physical layer which in the 
Amateur environment is usually the HDLC Controller chip. 
The physical layer acts on the commands from the datalink 
layer and returns data and status information to the 
datalink layer by means of status lines and interrupts. 


The datalink layer also communicates to the datalink 
layer on the other side of the link. 


Even though it is only the third of these interfaces 
which is the subject of this paper, it should be realized 
that in a real implementation of a datalink protocol there 
are actually three different protocols involved: i.e. the 
three communication interfaces. The type of protocols used 
for adjacent level communication are very system dependent 
but I will discuss in a general way, the type of information 
that is exchanged between the Network and Datalink layers. 


Interface with the Network layer 


Commands to the datalink layer and data to be passed 
accross the link are passed from the network layer to the 
Gatalink layer. The basic commands needed are: 


1. Link =- This iS a command which orders the datalink 
layer to establish a link. The data passed with this 
command indicates what type of link (either Full or Half 
Duplex) is desired and the node name of the node to be 
linked to. 


2e Unlink = This is a command which orders the datalink 
layer to terminate a link. 


Status information and information received from the 
link in I-eframes are passed to the Network layer from the 
Gatalink layer. The following status information should be 
passed: 


be 
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b A When a datalink becomes established. The type of link 
and node name should be passed as well. 


Zs When a datalink is terminated. The reason code and node 
name should be passed as well. 


3. Whenever a predetermined number of consecutive timeouts 
(N1) on a link has occurred. 


4. When an invalid frame is received on a link. 


The above lists are not necessarily complete but should 
serve to give the reader a good idea of the type of 
information needed. Each implementation will have its own 
method of handling these interfaces and it is not the intent 
of this paper to give detailed information as to how the 
information is to be passed. 


13. Sample Exchanges 


SAMPLE EXCHANGE 


The following example shows a V=2 exchange with no 
errors or exceptional situations encountered. It is beyond 
the scope of this paper to show an example of all possible 
types of exchanges. It is hoped that the information in 
this paper will be sufficient for the reader to determine 
what the exchanges would be when receive timeouts, lost 
frames, invalid frames, and colliding frames are 
encountered. The A,C and Iefields are shown separated by 
commas. The address field is displayed in hexadecimal. The 
control field is represented as follows: 


T (NS) P (Nr) 


Where T is the frame type acronym and P is the poll 
ee ee The (NS) and (Nr) are only shown for frames which 
contain them and the P is only shown if the poll bit is on 
C2) 


The Network header sub-field in the Iefield in I frames 
is shown in Hexadecimal characters and the rest of the I- 
field is shown in ASCII characters. The subfields in XID and 
DISC frames are shown separated by commas, the node names 
being in ASCII characters and the P, T and R fields in 
Hexadecimal. Time progresses downward in the _ following 
charts. 


The communication is between two nodes. Here is the 
pertinent information about the two nodes. 


Call sigh VE7APUI] KA6M 
Node number 627B 68ED 


Exchange l. 

This example shows link establishment, information 
transfer and link termination. A complete QSO. Arrows to 
the right indicate transmissions from VE7APU and those to 
the left indicate transmissions from KA6M. 


68ED627B,1(8)P(B) ,8188,Hello Hank -~---~-------- --> 
(2------------- 627B68ED,1(8)P(1) ,8108,Goodbye Doug 
68ED627B,RR(1) ------------------------------ -----> 


68ED627B,DISC=P,VE7APU1,KA6M »P=80,T=80,R=80 --=> 


Cewmme §27/B68ED,DISC,KA6M *VEJAPUL, P=08,T=88,R=80 


3-7 


13. Sample Exchanges 


The first line shows VE7APU has entered the link 
establishment phase at request of the Network level and is 
trying to initiate (Poll bit is on) a half duplex link (Link 
Type = 60) with KA6M using version @ level protocol 
(Protocol = @1). Because the Poll bit 1S on we Know VE7APU 
has started a line timeout. 


The second line shows KA6M has entered the link 
establishment phase and is responding (the Poll bit is off) 
positively (the Reason field = 88) using version @ level 
protocol. When this frame is received, VE7APU will enter 
the information transfer phase and cancel the line timeout. 


The third line shows VE7AP. sending an I-frame with 
data to KA6M and demands a response from KA6M (the Poll bit 
is on). VE7APU starts a line timeout at this time. When 
KA6M receives this frame it will enter the information 
transfer phase. 


The fourth line shows KA6M sending an I=-frame with data 
and acknowledging correct reception of VE7APU’s I-frame 
(Nr=1). It is demanding a response from VE7APU and starts a 
line timeout. 


The fifth line shows VE7APU acknowledging KA6Ms I~ 
frame by sending a Receive~Ready (RR) frame with Nr set to 
i. It has cancelled its receive timeout. The Poll bit is 
not on so VE7APU is not demanding a response from KA6M and 
so does not start a line timeout. VE/7APU could have sent an 
I-frame at this point if it had any information to send. 


The sixth line shows VE7APU has entered the link 
termination phase on orders from higher levels and is 
sending a DISC frame to KA6M to request termination of the 
link. The termination has not been caused by an error 
condition because the Reason field is @@Q. VE7APU is 
demanding a response from KA6M and starts a receive timeout. 


In the last line, KA6M enters the link termination 
phase when it receives the DISC frame and responds (Poll bit 
is off) with a DISC frame. After transmitting this frame, 
KA6M goes into the unlinked state. 


Since there are no further transmissions on the link we 


know that VE7APU has received the DISC, cancelled its 
receive timeout, and gone into the unlinked state. 
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14. Restrictions and Limitations 


RESTRICTIONS AND LIMITATIONS 


1. This protocol will not function correctly if a node in 
the information transfer phase can hear frames from another 
node which is also in the information transfer phase and is 
using the same four=byte link address. Note that this would 
require two pairs (4) of nodes active on the same channel 
each pair using the same node number. One node from each 
pair would have to be linked with one node from the other 
pair. The probability of this situation arising is 
extremely low. (Somewhat similar to the probability of the 
FCC or DOC issueing the same call to two different 
stations!). According to my recollection of probability 
theory, probability of any conflict is: 


N(N=1) 
(216-78) 2 


where N is the number of active links on the channel. Note 
that the probability is reduced even further if not all 
nodes can hear every other node. 


2. Although multiple links are allowed, a link will not be 
established to two nodes with the same address at the same 
time. The reason the link is not established is passed to 
the other node and corrective action could be taken = 
perhaps by changing the call sign suffix. 


3. Multiple links between the same nodes are not allowed. 
The need for this feature is questionable as all necessary 
data traffic accross the link should be able to be 
multiplexed by the higher levels of protocol. Although not 
defined in this protocol, a node could masquerade as a 
different node by supporting multiple node addresses and 
names by changing the call sign suffix. 


4. This protocol only supports datalinks between pairs of 
nodes. Thus it does not support conferencing or roundtable 
communication among a group of nodes. This function is 
normally provided by higher levels of protocol. The 
complications and problems encountered in providing data 
integrity with this service at the datalink level are severe 
and I do not know of any commercial or Amateur datalink 
protocols which do this. However, a form of roundtable 
operation could be implemented which does not guarantee data 
integrity. Each node in the group could operate in unlinked 
mode transmitting and receiving data in UI frames. The 
members of the group could agree to all use a broadcast 
address FFxx (where xx=a group number) in the destination 
part of the link address and then only pass information from 
frames which had a link address of this form. Members of 
the group should be in good communication with each other 
because there is no way of recovering data from lost frames 
when using this method of conferencing. 
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15. Comparisons 


IMPROVEMENTS OVER THE OLD VANCOUVER PROTOCOL. 

1. Both full and half-duplex links are provided for. 
2. Multiple links are supported. 

3. Some multiple protocol support. 

4. Vastly increased number of link and node addresses. 
5. No coordination of node addresses is required. 


6. A rudimentary conferencing system is provided. 


COMPARISON OF V=2 AND AX.25 


I am including this section because I am sure that many 
people will make comparisons and also because AX.25 is the 
only other Amateur Radio packet protocol which has a 
published specification document. 

This comparison is difficult to do because despite 
Statements in the literature that Ax.25 is a link level 
protocol, it is, in fact, a type of network level protocol. 
AX.25 routes packets through a series of links from a source 
node to a destination node, Although Ax.25 provides end~to-= 
end flow control, sequencing and data integrity, it provides 
no link level error recovery, retransmissions, 
acknowledgements, sequence checking, etc. for any of the 
links in the chain. Only in the special case where the 
source and destination are connected by a single link could 
AX.25 be construed to be a link level protocol. In this 
special case, the end points of the connection become 
identical to the end points of the link and so the end-to- 
end connection facilities cannot be distinguished from the 
link facilities. Some comparison of the two protocols can 
be done when considering this special case. 


A document describing a Network level protocol for V=2 
will be published later. Routing of packets through a 
network is one of the responsibilities of the Network level. 
Code for a Network level is being written at the present 
time for the VADCG TNC. Code for this link level protocol 
has been implemented on the VADCG TNC and on an IBM PC using 
a special board with an 8273 on it. 


1. V=2 has a reduced protocol overhead compared to Ax.25. A 
4=byte fixed length address field as opposed to a ]4=byte or 
Greater address field in AxX.25. 


2. V=2 has a facility to select fulleduplex or half duplex 
protocols at link establishment. 


15. Comparisons 


3. V-2 has a facility to select different protocols at link 
establishment. 


4. V=2 uses an addesssing and naming system for nodes. Ax-= 
25 makes no distinction between names and addresses. Names 
are for the convenience of the users. A call sign (name) is 
easy for the end user to use to identify nodes. Addresses 
are for convenience of the network. The two byte node 
address allows efficient use of selective receive and 
reduces overhead on the datalink. 


5S. AX.25 has a network routing system V=-2 link level does 
not. 


6. V=2 does not bit shift call signs and other names when 
transmitted. 


7e V=2 makes use of the selective receive function of the 
SDLC/HDLC protocol controller chips to automatically 
eliminate frames that do not need to be checked. AX.25 
cannot do this. For example, in this area, all call signs 
Start with the character V. Using AX.25, this would mean 
that all frames transmitted in this area would have the same 
character after the initial flag in every frame. This 
effectively renders useless the selective receive function 
present on the protocol controller chips and forces the 
software to read into memory and examine every frame that is 
transmitted on the channel. 


8. The V=2 datalink level does not specify the protocol 
used in the network level as does AxX.25. V=-2 identifies the 
protocol for level 3 in the level 3 (network) header. 


9. V=-2 link level has more symmetry than Ax.25. This is 


even more pronounced after the recent changes in the P/F bit 
Specifications for Ax.25. 
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16. Summary 


SUMMARY 


The general specifications of the V=2 protocol have 
been presented in this paper. As this 1S an early draft of 
a new protocol, some details may have been omitted. This 
document will be revised as necessary, to expand on areas 
not clearly presented and to include changes in the 
protocol. Those interested in obtaining the latest version 
of this document should contact the author. Anyone having 
questions or comments should do the same, preferably by 
writing. We would especially like to receive suggestions 
for improvement and would like to be copied on any 
correspondence regarding this protocol. 


At the present time (September, 1984) all but the full 
duplex mode of this protocol has been implemented in the 
VADCG TNC. The source code for this implementation is 
available on CP/M 8-inch diskettes. Anyone wishing to 
implement it on another system should contact the author 
directly so that the work may be coordinated. 


The author feels that V=-2 link level is an efficient 
protocol both in terms of channel utilization and software 
requirements and that it is particularly Suited to the 
Amateur Radio environment. It provides almost all the 
functions required by the ISO data link model without 
overstepping into functions in the domain of other layers. 
Its modularity allows it to be used as a building block upon 
which higher levels of protocol can be independently 
developed as per the ISO proposals. The V=2 protocol 
described in this document is not intended to be a standard 
but a stepping stone to improvement of Amateur datalink 
protocols. There is still need for improvement and V-=2 
still has some deficiencies which will result in additional 
changes in these specifications. 
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Appendix A 


APPENDIX A. Node Address Calculation 

The CRC-16 (16=<bit CRC) algorithm divides the 7=byte 
character string of the Node Name by the following 
generating polynomial: 


xe 4 x4 ek? ad 


This is the same polynomial used in calculating the FCS 
field by the various HDLC/SDLC protocol controller chips. 
In the calculation, integer quotient digits are ignored and 
the 16-bit remainder is checked to see that the first byte 
is not FF (Hexadecimal) and if it is, the bytes are 
reversed. If the first digit is still FF the value used is 
9228. This playing around with the value is done to ensure 
that none of the special purpose addresses beginning with FF 
are generated. 


Many of you out there may find this a little difficult 
to understand so I am including a sample assembly language 
program listing below which actually does the above 
generation for an 8@88 microprocessor. It should not be 
Gifficult to implement in other processors. 


Program Listing. 


ROUTINE TO GENERATE A NODE ADDRESS FROM A NODE NAME 

WHEN CALLED, IT USES THE NODE NAME AT LOCATION “NODENM’ AND 
LEAVES ITS NODE ADDRESS AT “CRC” UPON RETURN 

IT DOES NOT GENERATE ADDRESSES WITH FF AS THE FIRST BYTE 


=e =e ~e@ EO 


0022 ADRCALC :ORG 8 

08200 210000 LXI H,@ ; INITIALIZE CRC 

0803 225108 SHLD CRC ; FIELD TO 6008 

8886 215308 LXI H,NODENM; POINT TO NODE NAME 
8229 1687 MVI D,? ; NO. OF CHARACTERS 
O0OB 7E LOOP; MOV A,M ; GET A CHARACTER 
G88C CD2D82 CALL CALCCRC ; GIVE IT TO CRC RIN 
O8BF 23 INX H ; POINT TO NEXT CHAR 
001@ 15 DCR D ; FINISHED ALL CHARS? 
8811 C2BB0G JNZ LOOP ; NO, GO BACK 

0814 2A5108 LHLD CRC ¢ GET THE CRC 

@@17 7D MOV A,L : IS FIRST BYTE Fr? 
09818 FEFF CPI BFFH 

GB1A CB RNZ ; NO, RETURN WITH ADR 
Q@81B 7C MOV A,H ; YES, BAD LUCK, 

@G81C 6F MOV L,A ; REVERSE THE BYTES 
@81D 26FF MVI H,OFFH 

OGiF 2251088 SHLD CRC 

8822 7D MOV A,L > NOW IS FIRST BYTE FF? 
0023 FEFF CPI OFFH 

0825 CB RNZ ¢ NO, RETURN WITH ADDRESS 
0826 210808 LXI H,@ * YES, BAD LUCK 

0829 225188 SHLD CRC ¢ SET ADDRESS TO 0888 
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BB2C 


@82D 
O22E 
8238 
8831 
0834 
8835 
0836 
083? 
0838 
8839 
OO3A 
8283B 
8B3C 
883D 
8842 
8841 
9043 
8044 
0845 
6847 
9248 
0849 
BB4C 
BB4F 
8858 


8@51 
9253 


O25A 


; AND RETURN, END 


; THIS IS THE ACTUAL CRC-16 CALCULATION ROUTINE 


C9 RET 
ES CALCCRC: PUSH 
8608 MVI 
4F MOV 
2A5100 LHLD 
79 CALCCRC1: MOV 
07 RLC 
4F MOV 
7D MOV 
17 RAL 
6F MOV 
IG MOV 
17 RAL 
67 MOV 
D24882 JNC 
“ae MOV 
FE1@ XRI 
67 MOV 
7D MOV 
EE21 XRI 
6F MOV 
@5 CALCCRC2? DCR 
C23402 JNZ 
225188 SHLD 
El POP 
C9 RET 
0800 CRC DW 


5645374158NODENM DB 


H 


ps 
Pre rror yp 0 oe = tt Y 


CCRC2 


~ ke» = We 


CALCCRC] 
CRE 
H 


Q * NODE ADDRESS 
“VE7APUI’ * NODE NAME 


